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(54) Network management framework 



(57) A generic managennent framework for a net- 
work management system enables management serv- 
ices and management agents to be added in use as re- 
quired. Management services can be loaded or plugged 
into the framework dynamically. As a result a manage- 
ment structure can be provided which is scalable and 



dynamic and can evolve as requirements change. Man- 
agement information is modelled as management 
beans. Network management adaptors can also be add- 
ed as required to the framework to support protocols 
such as HTTP, SSL, RMI, SNMP. Remote applications 
can thereby control the management beans remotely 
through different protocols. 
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Description 

BACKGROUND OF THE INVENTION 

[0001] The present invention relates to network man- 
agement systems and to a framework and methods for 
such systems. 

[0002] Network management systems find applica- 
tion to the management of systems remotely via a tele- 
communications system. Network management sys- 
tems are known which permit the manipulation and con- 
trol of a large number and variety of objects over a net- 
work in accordance with a relatively limited set of com- 
mands, including operations such as GET, SET, AC- 
TION, CREATE and DELETE. An example of such a 
network management system is the so-called Telecom- 
munications Management Network (TMN) environment. 
[0003] The TMN environment provides an industry 
standard Common Management Information Protocol 
(CMIP) and supports X710/ISO 9595 Common Man- 
agement Information Services (CMIS) under that proto- 
col. These services allow manipulation of a large 
number and variety of objects over a network in accord- 
ance with a relatively limited set of commands, including 
operations such as GET SET, ACTION, CREATE and 
DELETE. 

[0004] The physical configuration of the network on 
which the network management system is configured 
can take many different forms, including, by way of ex- 
ample, a public switched telephone network and/or a lo- 
cal area network and/or a dedicated network connecting 
computer and other equipment within a local area and/ 
or over a wider area or an open network such as the 
Internet or an intranet. The objects typically comprise 
parameters and methods used to model a piece of 
equipment, a component of that equipment, an opera- 
tion of the equipment or a component thereof, and so on. 
[0005] In the TMN environment, for example, objects 
are defined in accordance with the industry standard 
X722/ISO-10165-4 Guidelines for Definition of Man- 
aged Objects (GDMO). The GDMO defines data, or pa- 
rameter, types in accordance with the X208/ISO-8824 
Abstract Syntax Notation One (ASN. 1) and the 
X209/ISO-8825 Specification of Basic Encoding Rules 
for Abstract Notation One (BER) for data notation. 
These various industry standards are defined by the In- 
ternational Standards Organisation (ISO). 
[0006] GDMO is a formal descriptive language which 
is not directly understood by a computer. It is therefore 
necessary to convert GDMO into a computer-under- 
standable format. As there is no standard for such a 
process, this often leads to multiple interpretations, 
which in turn leads to inter-operability problems. 
[0007] In order to invoke the CMIS, it is necessary to 
provide an Application Programming Interface (API). 
Typically, APIs have been created using programming 
languages such as C or C++. However, a program- 
based API for the ASN. 1 and GDMO standards runs into 



difficulties when there is a need to expand the network 
services, for example by defining new types and in- 
stances of objects (e.g., a new type of workstation for a 
network manager). Another problem with existing net- 

5 work management systems is that they are restricted as 
to the protocols which the network management agents 
can support. In other words, the conventional approach 
to providing an API is problematic in a dynamic network 
management environment. 

10 [0008] A general aim of the invention is to provide a 
structures which enable the development of a more flex- 
ible network management environment. Within this gen- 
eral aim, a more particular problem to which the present 
invention is directed is the provision of a dynamic net- 

^5 work management agent structure. 

SUMMARY OF THE INVENTION 

[0009] Particular and preferred aspects of the inven- 
20 tion are set out in the accompanying independent and 
dependent claims. Features of the dependent claims 
may be combined with those of the independent claims 
as appropriate and in combinations other than those ex- 
plicitly set out in the claims. 
25 [0010] In accordance with one aspect of the invention, 
there is provided a network agent for a telecommunica- 
tions network, the network agent comprising: an exten- 
sible framework; one or more managed objects regis- 
terable with the framework; and one or more network 
30 adaptors for a network communications protocol regis- 
terable with the framework for enabling access to the 
managed objects. 

[0011] By the provision of an extensible framework for 
a network agent with managed objects and network 

55 adaptors which can be associated, or registered, with 
the framework, a flexible network agent, for example a 
network management agent, can be provided which can 
be extended in an adaptable manner to suit changing 
circumstances. By enabling the association, or registra- 

40 tion, of different managed objects as required, the ex- 
tension of the structure to incorporate new objects for 
managing new or changes resources can readily be en- 
abled. By permitting selective connection of different 
network adaptors, which are preferably implements as 

45 objects, the protocols for managing the managed ob- 
jects can be selected as required. 
[0012] US patent 5,31 5,703 and US patent 5,367,633 
describe object-based systems which include a frame- 
work for permitting change notification functions. How- 

50 ever, these patents describe stand-alone systems. 

[0013] Preferably, management services can be reg- 
istered with the framework in a dynamic manner to pro- 
vide a scalable management environment. The man- 
agement services are preferably implemented in the 

55 form of objects registrable with the framework. One ex- 
ample of a management service is a repository service. 
[0014] In a preferred embodiment a repository service 
object is registrable with the framework, the managed 
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object(s) and/or the network adaptor(s) (and/or further 
management services) being registrable with the repos- 
itory service object, whereby the managed object and 
the network adaptors are registerable indirectly with the 
framework via the repository service object. The frame- s 
work can then make access to the managed objects and 
network adaptors via, or by referencing, the repository 
object. The repository service object effectively provides 
a connection mechanism between the framework and 
the managed objects and the network adaptors. This fo 
provides a particularly flexible structure for dynamic ex- 
tension of the agent structure. 

[0015] In a preferred implementation of the invention, 
the objects are implemented as beans, for example as 
JavaBeans components (JavaBeans is a trademark of ^5 
Sun Microsystems, Inc.). Beans are reusable software 
components which can be manipulated visually in a 
builder tool (e.g. an editor or graphical user interface 
builder (GUI builder)). An example of a builder tool is the 
JavaBeans Development Kit. Further details about 20 
beans can be found in many different works, for example 
in a book entitled Mastering JavaBeans by Lawrence 
Vanhelsuwe published by Sybex (ISBN 0-7821 -2097-0). 
This is just one example of many broadly equivalent 
books on the market having "JavaBeans" in the title and 25 
describing the JavaBeans. Many of these works, includ- 
ing the book Mastering JavaBeans, supply the Bean De- 
velopment Kit mentioned above. 
[0016] Beans vary in functionality, but they typically 
share certain common defining features providing a set 30 
of properties, a set of methods and support for events 
and for introspection, also known as reflection. The 
properties allow beans to be manipulated programmat- 
ically and support customization of the bean. The meth- 
ods implement the properties. The support for events 55 
enables beans to fire events and define the events 
which can be fired. The support for introspection ena- 
bles the properties, events and methods of the bean to 
be inspected externally 

[0017] Preferably, the framework comprises getter 40 
and setter properties and implements getter and setter 
methods for getting and/or setting objects and/or object 
methods. For providing the remote manipulation of the 
objects, the network adaptor(s) is/are responsive to a 
received external request to cause the framework to get 45 
a managed object method for the request and to return 
a subsequent response. Where the repository service 
is provided, the framework references the repository 
service for calling the managed object method. Prefer- 
ably the framework is arranged to effect add object and 50 
remove object functions for implementing dynamic scal- 
ing of the management structure. The framework is pref- 
erably implemented as a bean including getter and set- 
ter properties, methods for implementing those proper- 
ties and support for add object and remove object 55 
events. 

[0018] In accordance with another aspect of the in- 
vention, there is provided a computing system connect- 



able to a telecommunications network, the computing 
system including a network agent, the network agent in- 
cluding: an extensible framework; one or more man- 
aged objects registerable with the framework; and one 
or more network adaptors registerable with the frame- 
work for a network communications protocol for ena- 
bling access to the managed objects. 
[0019] In accordance with a further aspect of the in- 
vention, there is provided an object-based network 
agent on a carrier medium (e.g. on at least one storage 
medium), the network agent comprising: an extensible 
framework service object; one or more managed objects 
registerable with the framework service; and one or 
more network adaptor objects registerable with the 
framework service for a network communications proto- 
col for enabling access to the managed objects. 
[0020] In accordance with another aspect of the in- 
vention, there is provided a network management sys- 
tem comprising a network management network agent 
for a managed system, the network management agent 
comprising: an extensible framework service object; 
one or more managed objects registerable with the 
framework service; and one or more network adaptor 
objects registerable with the framework service for a 
network communications protocol for enabling access 
to the managed objects. 

[0021] In accordance with a further aspect of the in- 
vention, there is provided a method of providing agent 
services via a telecommunication network, the method 
comprising steps of: dynamically registering one or 
more managed objects with an extensible agent frame- 
work; registering one or more network adaptors for a 
network communications protocol with the framework; 
and enabling access to the managed object(s) via the 
network adaptor(s). 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0022] Exemplary embodiments of the present inven- 
tion will be described hereinafter, by way of example on- 
ly, with reference to the accompanying drawings in 
which like reference signs relate to like elements and in 
which: 

Figure 1 is a schematic representation of three sta- 
tions connected via a telecommunications network; 
Figures 2 and 2A form a schematic representation 
of a computer server for a station of Figure 1 ; 
Figure 3 is a schematic representation of an agent 
for a managed station; 

Figure 4 is an alternative representation of the 
agent of Figure 3; 

Figure 5 is an example of a configuration for an 
agent; 

Figure 6 is a flow diagram illustrating operations us- 
ing an agent as shown in Figure 5; 
Figure 7 is an example of a configuration of a man- 
agement system; 
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Figure 8 is anotlner example of a configuration of a 
management system; 

Figure 9 illustrates an aspect of the creation of the 
configuration of Figure 8; 

Figure 10 is a flow diagram illustrating operations 
of the system of Figure 8; 

Figure 11 is a flow diagram illustrating the operation 
of a naming service; 

Figure 1 2 is a flow diagram illustrating the operation 
of the creation of a generic agent; 
Figures 13 and 14 illustrate alternative operations 
of a compiler; 

Figures 1 5A and 1 5B are used to illustrate the effect 
of compiling a management bean; 
Figures 1 6A and 1 6B are also used to illustrate the 
effect of compiling a management bean; and 
Figure 1 7 is a flow diagram illustrating steps in gen- 
erating a management system. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0023] Figure 1 is a schematic representation of a 
multi-station network based system 1 with three sta- 
tions, or nodes, or machines 3, 4 and 5 connected via 
a network 2. The network 2 can be based on a public 
switched telephone network and/or a local area network 
and/or a dedicated network connecting computer and 
other equipment within a local area and/or over a wider 
area and/or an open network such as the Internet or an 
intranet, or combination thereof or indeed any other type 
of telecommunications network which can support the 
exchange of telecommunications management infor- 
mation. The network can have any desired structure, 
such as a level structure, a pyramidal hierarchy, etc. 
[0024] Any one or more of the stations 3, 4 or 5 can 
be configured as a network management station. In the 
example shown in Figure 1 , it is assumed that station 3 
is a management station and stations 4 and 5 are man- 
aged stations. It will be appreciated that any number of 
management stations and managed stations may be 
provided and that the three stations of Figure 1 are for 
illustrative purposes only Also, the managing and man- 
aged functions could be interchanged or indeed both 
managing and managed functions could be supported 
at one and the same station. 

[0025] The stations can take on many forms. For the 
purposes of illustration it is assumed that both comprise 
computer workstations. Figure 2 is a schematic repre- 
sentation of the configuration of a computer workstation. 
As illustrated in Figure 2, this is implemented by a server 
computer 10 comprising a system unit 11 with a display 
8, keyboard and other input devices 9. Figure 2A is a 
schematic block representation of aspects of the con- 
tents of the system unit 11. As illustrated in Figure 2A, 
the system unit includes a processor 17, memory 18, 
magnetic and/or optical disk drives 13 and 14, and a 
communications adaptor 16 for connection to one or 



more telecommunication lines 15 for connection to the 
telecommunications network 2. As illustrated in Figure 
2A, the components of the system unit are connected 
via a bus arrangement 1 9. It will be appreciated that Fig- 
5 ures 2/2A are a general schematic representation of one 
possible configuration for a server computer for forming 
a router. It will be appreciated that many alternative con- 
figurations could be provided. 

[0026] Where the workstation implements a manage- 

fo ment station, management application or applications 
and interface structures are typically provided by soft- 
ware which is stored in the memory of the workstation 
and executed by the processor of the workstation. 
[0027] Where the workstation implements a managed 

^5 station, an agent is responsive to remote management 
requests via the network from the management applica- 
tions to provide an interface to managed objects at the 
managed stations. The agent and managed object 
structures are typically provided by software which is 

20 stored in the memory of the workstation and executed 
by the processor of the workstation. 
[0028] The objects typically comprise parameters and 
methods used to model a piece of equipment, a compo- 
nent of that equipment, an operation of the equipment 

25 or a component or resource thereof, and so on. 

[0029] The management of a telecommunications 
network requires applications of various sizes and com- 
plexities. Heavy managers, middle managers, extensi- 
ble agents, smart agents and appliances all have a role 

30 in the management of a telecommunications network. A 
network management system incorporating the present 
invention provides an extensible agent framework al- 
lowing all of these different application types to be built 
on the same architecture. This extensible agent frame- 

55 work is provided by a component of the network man- 
agement system. Alternative terms for the extensible 
agent framework in this context could be a "dynamic 
framework" or "open framework" or "runtime compo- 
nent", although the terms "framework" or "extensible 

40 agent framework" will be used herein. 

[0030] The network management system is supplied 
with a set of core management services. A choice can 
be made from this set of services, and it can be extended 
to develop specific applications. Different services are 

45 loaded statically or dynamically into the framework to 
meet the requirements of a particular application. 
[0031] A managed object in an example of a network 
agent incorporating the present invention is preferably 
implemented as a bean, more preferably a JavaBeans 

50 component. A bean (and a JavaBeans component) is a 
reusable software component which can be manipulat- 
ed visually in a builder tool (e.g. an editor or graphical 
user interface builder (GUI builder). An example of a 
builder tool is the JavaBeans Development Kit. Beans 

55 vary in functionality, but they typically share certain com- 
mon defining features providing a set of properties, a 
set of methods for performing actions, and support for 
events and for introspection. The properties allow beans 
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to be manipulated prog ram mat ically and support cus- 
tomization of tine bean. The metlnods implement the 
properties. The support for events enables beans to fire 
events and define the events which can be fired. The 
support for introspection enables the properties, events 
and methods of the bean to be inspected from external- 
ly. Operations such as GET, SET, ACTION, CREATE 
and DELETE can be supported. 
[0032] A managed object in the agent is manageable 
as soon as it is registered with the framework. This ar- 
rangement enables an agent developed in accordance 
with this network management system to be managea- 
ble with minimal impact on the design of the agent. 
[0033] As indicated above, an example of the network 
management system uses the JavaBeans component 
model, thereby easing the development of applications. 
In this example, all of the core management services 
are provided as JavaBeans components. Thus access 
can be had to them using a Java application builder, 
such as the well known JavaBeans Development Kit. 
Managed objects are developed as JavaBeans compo- 
nents. A JavaBeans component in the network manage- 
ment system agent can be accessed locally or remotely. 
This means that when developing managed objects with 
the network management system, it is not necessary to 
know to which communications protocol the managed 
object will be accessed. 

[0034] The network management system simplifies 
the development of extensible agents. A set of core 
management sen/ices that the network management 
system provides can be extended and loaded into an 
agent while it is running. Most of the core management 
services are optional. This means that an agent devel- 
oped using the network management system need only 
implement the service it uses. This feature enables the 
development of agents of differing sizes and complexi- 
ties. 

[0035] Agents developed using the network manage- 
ment system are also smart agents. A smart agent pro- 
vides the services needed to process management re- 
quests. In a smart agent, much of the processing can 
be done locally in the agent itself, reducing the load on 
the network connection between the agent and manag- 
ing system. 

[0036] Figure 3 illustrates an aspect of the architec- 
ture of a network management system agent, including 
the relationships between the components of the net- 
work management system. Figure 3 also shows the re- 
lationship between the network management system 
agent and management applications. 
[0037] As shown in Figure 3, the network manage- 
ment system agent consists of a number of components 
inside a Java virtual machine (VM). These include: 

m-beans 29; 

the framework 24; 

core management services 25, 26, 27, 28; 
managed objects adaptor servers 30, 32, 34, 36 



and 38. 

These components will be described in more detail be- 
low. 

5 [0038] A managed object is a software abstraction 
of a resource that is controlled and monitored by an 
agent. A managed object (eg. 28) is referred to as a 
management bean or m-bean. In an example of the net- 
work management system, all m-beans are implement- 
ed ed as JavaBeans components. Therefore, these can be 
accessed using a conventional Java application builder, 
such as the JavaBeans Development Kit mentioned 
earlier. 

[0039] As for any other managed object, an m-bean 
15 has a set of properties, can perform a set of actions, and 
can emit a set of notifications or events. The network 
management system enables a distinction to be made 
between a read-only and a read-write property in an m- 
bean. 

20 [0040] An m-bean is manageable as soon as it is reg- 
istered with the framework 24. When an m-bean is reg- 
istered, an object name is associated with it. The object 
name uniquely identifies the m-bean within the m-bean 
repository (see below). It enables a management appli- 

25 cation to identify the m-bean on which it is to perform a 
management operation. The object name of an m-bean 
is an arbitrary name that does not depend in any way 
on how the m-bean is implemented. 
[0041] The framework 24 controls the management 

30 services and m-beans of an agent 20 are loaded into 
the framework 24. The framework, or runtime compo- 
nent, 24 is a JavaBeans component which comprises a 
set of properties, a set of methods for performing ac- 
tions, and support for events and for introspection. The 

35 properties include getter and setter properties. The 
methods include methods to implement the getter and 
setter properties. The framework is also able to effect 
add object and remove object functions. 
[0042] Whenever an agent 20 is requested to perform 

40 a management operation received through a network 
adaptor, the framework 24 calls the appropriate service 
to perform the requested operation. The framework 24 
also handles communications between m-beans 28 and 
the managed object adaptor servers 30-38. An m-bean 

45 can query the framework 24 to obtain information on oth- 
er m-beans 28 loaded into the same instance of the 
framework 24. Only one instance of the framework 24 
is permitted within a virtual machine 22. 
[0043] The network management system provides a 

50 number of core management services. In an example 
of the system, the core management services are de- 
fined as Java interfaces. The core management servic- 
es are optional. This means that an agent developed 
using the network management system need only im- 

55 plement the services it uses. The core management 
services can be registered as m-beans, which allows 
some management operations to be formed on them for 
tuning their behaviour. 
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[0044] In the preferred example of the system, the 
core management services are provided as JavaBeans 
components. It is therefore possible to access them us- 
ing a conventional Java application builder, such as the 
JavaBeans Development Kit mentioned earlier. 
[0045] A number of the core management services 
are now to be described. 

[0046] The m-bean repository service 27 obtains 
pointers to m-beans. Each time an m-bean is registered 
with the framework 24, the framework 24 calls the m- 
bean repository service 27 to store the identity of the m- 
bean. A name is associated with an m-bean. When que- 
rying the m-bean repository 27, agent and manager ap- 
plications can identify an m-bean by its name. Different 
implementations of the m-bean repository service 27 
are possible. One implementation uses a relational da- 
tabase for storing persistent m-beans, whereas another 
implementation employs simple memory for storing 
non-persistent m-beans. 

[0047] Bearing in mind the structure provided by the 
repository unit, an alternative representation of the re- 
lationship between components of the agent is illustrat- 
ed in Figure 4. This takes account of the registration of 
the beans for the managed object adaptor servers, the 
management services and the managed objects with 
the m-bean repository service bean. 
[0048] A filtering service 29 selects m-beans to be 
the subject of a management operation. Selection is 
based on the presence and values of specific attributes. 
For example, a filter could select all the m-beans for 
which the attribute color is set to red. 
[0049] A metadata service 25 provides information 
on the structure of an m-bean. For example, the frame- 
work 24 queries the metadata service 25 to access 
methods for getting and setting up a property within an 
m-bean. The metadata service 25 is based on the Re- 
flection API provided by the JavaBeans Development 
Kit for performing introspection. 

[0050] A dynamic class loading service loads new 
classes into the framework 24. A new class is loaded 
when the remote entry requests the creation of instanc- 
es of a class that is not loaded into the framework 24. A 
new class can be loaded from a remote class server. 
The dynamic loading service also enables core man- 
agement services to be added to a network manage- 
ment system agent while it is running. For example, an 
agent could be started without a filtering service. Then, 
later on, the filtering service could be added dynamically 
to the agent when it is required. 

[0051] An access controi service can be provided 
to control access to m-beans. Before attempting to per- 
form a management operation on an m-bean, the frame- 
work 24 can be arranged to query the access control 
service to verify that the operation is valid. 
[0052] An event service can be provided to receive 
event reports from m-beans and to forward them to any 
entity that has requested to receive them. 
[0053] A relationship service can be provided to en- 



able relationships between m-beans to be defined when 
they are required. The relationships do not need to be 
defined in advance. Information on the relationships be- 
tween m-beans is not stored with the m-beans them- 
5 selves, but can be obtained from the relationship serv- 
ice. 

[0054] A dynamic native library loading service 

can be provided for loading native code into the frame- 
work 24. A native library can be loaded when a new 

fo class that includes native code is loaded. The library 
loaded depends on the hardware platform and operating 
system on which the framework is running. The native 
library can be loaded from a remote entity. 
[0055] There now follows a description of the man- 

^5 aged object adaptor servers 30-38. 

[0056] A managed object adaptor server is a proto- 
col adaptor that provides an abstraction of a communi- 
cations protocol. Each managed object adaptor server 
provides access to m-beans through a particular com- 

20 munications protocol. A managed object adaptor server 
enables management applications to perform manage- 
ment operations on a network management system 
agent. 

[0057] For a network management system agent to 
25 be manageable, it is connected via at least one man- 
aged object adaptor server. However, a network man- 
agement system agent can be connected to any number 
of managed object adaptor servers, allowing it to be 
queried by remote management applications that use 
30 different protocols. 

[0058] The network management system provides 
managed object adaptor servers for standard and pro- 
prietary protocols. 

[0059] For example, managed object adaptor servers 
55 can be provided for one or more of the standard proto- 
cols: HTML/HTTP; SNMP; and CORBA, by way of ex- 
ample. 

[0060] The managed object adaptor servers for 
standard protocols communicate directly with the man- 

40 agement applications that use them. 

[0061] For example, an HTMLyHTTP managed object 
adaptor server enables a user to use a web browser to 
view management information contained in m-beans 
and to perform management operations on a network 

45 management system agent. The HTTP/HTML managed 
object adaptor server obtains management information 
from m-beans and generates HTML pages representing 
this management information. 

[0062] An SNMP managed object adaptor server can 
50 be arranged to use a specially defined SNMP manage- 
ment information base (MIB) to enable the SNMP man- 
ager to perform management operations on a network 
management system agent. 

[0063] The network management system can also be 
55 arranged to provide managed object adaptor servers for 
one or more of the following proprietary protocols: RMI; 
Java/HTTP; and Secure Sockets Layer (SSL). In one 
example of the network management system, a man- 
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aged object adaptor client offers a Java API. According- 
ly, any management application that uses a managed 
object adaptor client will be written in Java language. 
[0064] Agents developed using the network manage- 
ment system can be managed using different commu- 
nications or management protocols. To be managed us- 
ing a standard management protocol, a network man- 
agement system agent needs to be connected to the 
managed object adaptor server for that protocol. The 
managed object adaptor service for standard protocols 
communicates directly with the management applica- 
tions that use them. 

[0065] An example of this structure, using the agent 
representation of Figure 4, is shown in Figure 5, where 
the agent is accessed by means of a web browser 46. 
Here an HTML adaptor allows beans to be mapped to 
an HTML page. The use of a protocol such as HTML 
enables the browser 46 at the client station 90 to browse 
beans at the remote station 20 and access and where 
necessary modify them using conventional web browser 
functions. In accordance with the structure shown in Fig- 
ure 4, the repository service 27 is registered with the 
framework 24, and the HTML adaptor 34 and the bean 
(s) 29 are registered with the repository service, where- 
by the bean(s) are effectively registered with an HTML 
page supported by the HTML adaptor 34. In Figure 5 
like reference numerals relate to like features of the ar- 
rangement shown in Figure 4. 

[0066] Figure 6 is a flow diagram illustrating steps for 
enabling the modification of properties of the beans in 
the remote machine. In step 92, the HTML adaptor 34 
is initiated in the virtual machine 22 at the remote station 
20 and in step 94 the bean(s) 29 of that virtual machine 
which are to be accessible remotely are registered with 
the framework, or more particularly with the repository 
service 27 as described above. This means that when 
the HTML adaptor queries the framework 24, the frame- 
work 24, with reference to the repository service, is able 
to identify the beans 29 to be accessed and to permit 
access thereto by the HTML adaptor. 
[0067] The HTML adaptor 34 allows communication 
over the network using conventional HTTP exchanges. 
It behaves as an HTTP server. When it receives a re- 
quest, it dynamically generates a page containing a list 
of beans (objects) 29 currently registered with the re- 
pository object 27. 

[0068] A bean is represented in HTML as an HTML 
table wherein: 

a first column contains a property name; 

a second column contains a property type; 

a third column contains the access right (read/ 

write); 

a fourth column contains a property value. 

[0069] As mentioned above, if the property is read/ 

write, an HTML form is generated. 

[0070] In step 96, the beans are displayed at the client 



station (represented by display 98) using the HTML rep- 
resentation of a bean as described above by accessing 
the HTML page using a conventional web browser 
which communicates with the HTML adaptor using HT- 

5 TP exchanges. The user is able then to select, at step 
100, a bean using conventional web browser functions. 
The web browser will then issue an HTTP GET request 
to the HTML adaptor 34. The HTML adaptor employs 
introspection to extract the bean properties and then re- 

fo turns an HTML post response to the browser, whereby 
the browser may display the properties, and possibly al- 
so the actions and events supported by the bean, as 
represented at 1 02. By further use of the browser using 
conventional browser functions, the user is able to se- 

^5 lect and specify modifications to aspects of the bean, for 
example changes to the properties. By a further ex- 
change of HTML GET and/or SET requests and POST 
responses, the web browser and the HTML adaptor are 
able to modify at step 1 04, the corresponding properties 

20 of the bean at the remote station and to display these 
changes to the user at the client station. 
[0071] Thus, this mechanism provides a computer- 
implemented method of accessing from a client ma- 
chine an object such as a bean at a remote machine via 

25 a telecommunications network by mapping the object to 
an externally accessible machine page at the remote 
machine and browsing the object via the machine page 
using a browser. 

[0072] Another example of the structure shown in Fig- 

30 ure 3, this time using the representation of Figure 3, is 
shown in Figure 7, where a network management sys- 
tem agent 20 is managed by an SNMP manager appli- 
cation. In Figure 7 like reference numerals relate to like 
features of the arrangement shown in Figure 3. 

55 [0073] An example of a network management system 
represented in Figure 8 provides an adaptor API to en- 
able Java management applications to communicate 
with the network management system agents. The 
adaptor API provides managed object adaptor clients 

40 for accessing managed objects through a particular 
communications protocol. The network management 
system defines a representation of m-beans for Java 
management applications and provides a compiling tool 
for generating such a representation automatically from 

45 an m-bean. A name service is supplied to allow Java 
management applications to be independent of a par- 
ticular communications protocol. 
[0074] A managed object adaptor client is an abstract 
Java class that enables Java management applications 

50 to access managed objects. The programmatic repre- 
sentation of the managed object to the Java manage- 
ment application is determined by the managed object 
adaptor client. Such a mechanism allows different rep- 
resentations of the same managed object to be present- 

55 ed to different Java management applications. The net- 
work management system provides managed object 
adaptor clients for accessing managed objects through 
one or more of the following protocols: RMI; HTTP; and 
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SSL 

[0075] The managed object adaptor clients provide a 
definition of an adaptor nnanaged object interface. Tine 
adaptor nnanaged object interface enables Java nnan- 
agement applications to perform one or more of the fol- 
lowing management operations on a network manage- 
ment system agent: 

retrieve m-beans; 

get or set the properties of remote m-beans; 
call methods of remote m-beans; 
create instances of m-beans; 
delete m-beans; and 

receive events emitted by remote m-beans. 

[0076] A managed object adaptor client provides a 
Java management application with "handles" on man- 
aged objects in a remote agent. These handles enable 
the Java management application to manipulate the 
managed objects directly. The Java management appli- 
cation does not need information on the protocol used 
by the managed object. All the Java management ap- 
plication needs is the class of object that the managed 
object represents. For example, a Java management 
application for handling accounts uses an abstract class 
for representing accounts. To manipulate an account, 
the Java management application obtains an account 
managed object from the managed object adaptor cli- 
ent. It then casts the account managed object into the 
abstract class that represents the account. In this way, 
the application code is independent of howthe managed 
object is implemented. 

[0077] Figure 8 is a schematic representation of the 
relationship between a client bean (c-bean) 54 and an 
m-bean 28. A c-bean 54 is a representation of an m- 
bean to a Java management application. In the pre- 
ferred embodiment of the invention, a c-bean 54, like an 
m-bean 28, is implemented as a JavaBeans compo- 
nent. A c-bean 54 defines how a Java management ap- 
plication accesses an m-bean 28. 
[0078] As seen in Figure 8, a c-bean 54 comprises a 
managed object interface (MO interface) 56 which de- 
fines which of the methods of an m-bean are accessible 
to a Java management application, and a managed ob- 
ject stub (MOStub) 58 that implements the methods de- 
fined in the MO interface 56. 

[0079] A Java management application obtains a ref- 
erence to a c-bean by using an adaptor MO interface 
60. The adaptor MO interface instantiates the c-bean 
54. The same implementation of a c-bean 54 can run 
on any managed object adaptor client that implements 
the adaptor MO interface 60. Different implementations 
of the same managed object can be presented to differ- 
ent Java management applications. Therefore, a single 
m-bean can be associated with several c-beans 54. 
[0080] A Java management application performs 
management operations on an m-bean by calling meth- 
ods of its associated c-bean 54. To the Java manage- 



ment application, a c-bean 54 is a local representation 
of the remote Java object (an m-bean 28). 
[0081] The adaptor MO interface 60 instantiates the 
c-bean 54. The same implementation of a c-bean can 
5 run on any managed object adaptor client 62 which im- 
plements the adaptor MO interface 60. Different repre- 
sentations of the same managed object can be present- 
ed to different Java management applications. Thus, a 
single m-bean can be associated with several c-beans. 
10 [0082] A Java management application performs 
management operations on a m-bean by calling meth- 
ods of its associated c-bean. To the Java management 
application, a c-bean is a local representation of a re- 
mote Java object (an m-bean). 
15 [0083] Figure 9 is a schematic representation of the 
generation of a c-bean 54 from an m-bean. In an em- 
bodiment of the invention a c-bean is generated auto- 
matically from an m-bean 28 using the Reflection API. 
The generated c-beans exhibit the same properties, 
20 methods and events as the m-beans. This is the case, 
for example, where no access control policy is enforced. 
[0084] In order to provide the automatic generation of 
a c-bean 54 from an m-bean 28, a compiler 60 takes as 
an input the m-bean 28 and generates as an output the 
25 MO interface and MO stubs of a c-bean 54. For exam- 
ple, when an m-bean 28 representing a Java class 
named account \s compiled, the compiler 60 generates 
an MO interface 56 named accountMO and a Java class 
named accountMOSTUB 58, which implements the ac- 
30 countMO interface 56. 

[0085] A Java management application can be devel- 
oped using the MO interface definitions. By loading dif- 
ferent stubs, the adaptorMO interface can modify the 
behaviour of the Java management application at run 
35 time. For example, if read-only stubs are loaded, the 
Java management application will not be able to modify 
the properties in the m-bean 28. 
[0086] The compiler 60 can generate read-only or 
read-write stubs. The generated stubs make use of the 
40 adaptorMO interface. Therefore, their behaviour is the 
same on any managed object adaptor client that imple- 
ments the acyapforMO interface, regardless of the imple- 
mentation of the managed object adaptor client. 
[0087] Figure 10 is a block diagram of steps for ac- 
45 cessing a bean at a remote (server) station from a local 
management (client) station using a structure as shown 
in Figure 8. 

[0088] The management application (e.g. a Java 
management application) at the management station 
50 generates, at step 80, a get request to the adaptorMO 
at the client station. The adaptorMO, with the Mostub 
and the network adaptor at the client station generate, 
at 81 , a request in accordance with an appropriate net- 
work protocol (e.g. HTTP). 
55 [0089] Thus the request sent via the network to the 
managed system could, for example, be in the form of 
a GET request for a management property of a man- 
aged object. 
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[0090] The appropriate managed object adaptor serv- 
er 30-38, depending on tine protocol used, receives tine 
external request at step 82. It will then access, at step 
83, the framework 24 to get an appropriate method. The 
framework gets, at step 83, a managed object method 
for the request and returns, at step 84, the management 
property of the managed object to the adaptor, which in 
turn returns, at step 85, composes a return message 
with the result in accordance with the same network pro- 
tocol (e.g. HTTP). The result message is received, at 
step 86, at the client adaptor and adaptorMO, which re- 
turns the result to the management application. 
[0091] A name service is provided which allows man- 
agement applications to be independent of a particular 
communications protocol. Java management applica- 
tions use the name service to determine which managed 
object adaptor client to use for accessing an agent. Fig- 
ure 1 1 is a schematic flow diagram illustrating the oper- 
ation of the name service. 

[0092] In step 62, the management application pass- 
es the identity of the agent to be accessed to the main 
service. 

[0093] In step 64, the name service returns the class 
name of the managed object adaptor client, for example 
sunw.jaw.moa.rmi in the case of an agent access 
through the Java RMI system. 

[0094] In step 66, the Java management application 
uses its default class loader to dynamically load the 
managed object adaptor client and instantiate it. The 
Java management application can then interact with the 
agent through the managed object adaptor client, re- 
gardless of the communications protocol. 
[0095] As mentioned above, a management bean, or 
m-bean is a managed object in a network management 
system agent. A managed object is a software abstrac- 
tion of a resource that is controlled and monitored by the 
agent. In an example of a network management system, 
all m-beans are implemented as JavaBeans compo- 
nents. They can be accessed using a conventional Java 
application builder, such as the Java Beans Develop- 
ment Kit. Within an m-bean, it is possible to call and use 
services provided by the network management system. 
[0096] A JavaBeans component includes properties 
which form discrete, named attributes which can affect 
the appearance or the behaviour of the JavaBeans com- 
ponent. For example, an m-bean representing an Ether- 
net driver might have a property named Ipackets that 
represents the number of incoming packets. Properties 
can have arbitrary values, including both built-in Java 
end types and class or interface types such as Java.awt. 
color. Properties are always accessed via method calls 
on the object that owns them. For readable properties 
there is a get method to read the property value. For 
writeable properties, there is a set method to allow the 
property value to be updated. 

[0097] A default design pattern can be used for locat- 
ing properties: 



public PropertyType get Property NameQ; 
public void set PropertyName (PropertyType val- 
ue); 

5 [0098] If a class definition contains a matching pair of 
get PropertyName and set PropertyName methods with 
the return type of the getter corresponding to the param- 
eter type of the setter, then these methods define a read- 
write property. If a class definition contains only one of 

10 these methods, the name defines either a read-only or 
write -only property called PropertyName. 
[0099] In addition for Boolean properties, it is possible 
to define a get method using the following design pat- 
tern: 

15 

public boolean isPropertyNameQ; 

[01 00] The \s PropertyName method may be provided 
instead of a geXPropertyName method where it may be 
20 provided in addition to a geXPropertyName method. 
[01 01] An index property is an array PropertyElement 
[], that is accessed by methods of the form: 

public PropertyElement geXPropertyName (int in- 
25 dex); 

public void setPropertyName (int index, Proper- 
tyElement b). 

[0102] If a class definition contains either kind of 
30 method, PropertyName is an index property. These 
methods can be used to read and write a property value. 
These methods can be defined in addition to the meth- 
ods defined for simple properties. Therefore, an index 
property can be represented by four accessor methods. 
35 [01 03] By default, the following design pattern is used 
to determine which events an m-bean can multicast: 

public void a66EventListenerType(EventListener- 
Type a); 

40 public removeEventListenerType(EventListener- 
Type a); 

[01 04] Both of these methods take the EventListener- 
Typetype argument, where the EventListenerTypeXype 
45 extends the Java. util. Event Listener '\nXerXace, where the 
first method starts with add, the second method starts 
with remove, and where the EventListenerType type 
name ends with Listener 

[0105] This design patent assumes that the Java 
50 bean is acting as a multicast event source for the event 
specified in the EventListenerType interface. 
[01 06] To conform to the JavaBeans model, all public 
methods of a JavaBeans component should be exposed 
as external methods within the component environment 
55 for access by the components. By default, this includes 
property accessor methods, and in the event listener 
registry method. 

[01 07] In addition to the JavaBeans component mod- 
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el for design pattern elements, the network nnanage- 
ment system can define an action as a public method of 
an m-bean that makes sense to be called remotely. Ac- 
tion facilitates the differentiation of an m-bean public 
method which is exposed for other local m-beans from 
public methods that can be called remotely. The design 
pattern for an action is as follows: 

public AnyJavaType performAnAction (AnySig na- 
ture); 

[0108] M-beans can contain native libraries, that is a 
library not written in the language (e.g. Java) of the m- 
bean. The network management system can provide a 
mechanism for loading a native library from the same 
remote class server as the m-beans. To enable an m- 
bean to use this mechanism, a static loadLibrary method 
of the Framework class can be called in which the caller 
includes a reference to the Java class of the caller. Such 
information is used by the framework 24 for identifying 
the class loader by which the class is loaded. 
[0109] The core management services mentioned 
above are for many of the management operations com- 
mon to all agents, thereby simplifying the development 
of agents. By providing these core services, the network 
management system enables efforts to be concentrated 
on developing those parts of an agent which are specific 
to a particular application, namely the m-beans and the 
applications to control and manage them. 
[0110] Figure 12 is a schematic flow diagram of the 
initialisation of a network management system agent 20. 
The initialisation process comprises: 

in step 70, creating an instance of the framework 24; 
in step 72, adding the m-bean repository service 27; 
in step 74, adding the metadata service 29; and 
in step 76, adding at least one managed object 
adaptor server (30-38) so that the agent can be ac- 
cess by management applications. 

[0111] Once the network management system agent 
20 has been initialised, no further management services 
need to be added before an agent is started. These can 
be added dynamically to the agent while it is running. 
[0112] The framework 24, controls the management 
services and m-beans of an agent 20 developed using 
the network management system. In the preferred em- 
bodiment it is implemented by the Java class java.jaw. 
agent. cmf. Framework. An agent must contain one in- 
stance of the framework, that is, in the preferred embod- 
iment, one instance of the java.jaw.agent. cmf. Frame- 
work class. 

[0113] In the preferred embodiment, m-beans can be 
managed only if they are registered with an object name 
in the m-bean repository 27 of the agent 20. Accordingly, 
the m-bean repository service 27 is added in step 72 
before the agent 20 becomes operational. The m-bean 
repository service 27 is used for storing and retrieving 



the association between an m-bean and its object name. 
The m-bean repository service of the preferred embod- 
iment is defined as the Java interface java.jaw.agent. 
services. MoRepSrvlf. An agent can only be associated 
5 with the one m-bean repository service at any one time. 
However, it is possible to change the m-bean repository 
service with which the agent is associated while the 
agent is running. 

[0114] The m-bean repository can be implemented as 

10 a volatile storage or as a persistent storage. In a volatile 
repository, all the information on m-beans is stored in 
memory. All of the information in a volatile repository is 
lost when the agent is stopped. Accordingly, when an 
agent is started, with a volatile repository, it has to reload 

15 the information in the repository. With a persistent re- 
pository, all the information on m-beans is stored in a 
database whereby the information in a persistent repos- 
itory is not lost when the agent is stopped. It is also pos- 
sible to implement a mixed repository whereby informa- 

20 tion on m-beans is stored in memory or in a database. 
[0115] The metadata service referenced above is 
used to obtain the properties and actions supported by 
an m-bean. A preferred implementation of the metadata 
service is based on the Reflection API provided by the 

25 known Java Development Kit for performing introspec- 
tion. 

[0116] As mentioned above, at least one managed 
object adaptor service should be running in the server 
virtual machine as the network management system 

30 agent. The network management system does not re- 
quire a managed object adaptor server to conform to a 
specific interface definition or implementation. The man- 
aged object adaptor server is arranged to access the 
framework 24 to retrieve and change information con- 

35 tained in the agent. The managed object adaptor serv- 
ers provided are implemented as m-beans. Examples 
of managed object adaptor servers have been de- 
scribed above. In the preferred embodiment of the in- 
vention, the managed object adaptor servers are imple- 

40 mented as appropriate Java classes. 

[0117] For example, an RMI managed object adaptor 
server can be implemented as a Java class sunw.jaw. 
agent.adaptor.rmi.AdaptorServerlmpl. It enables Java 
management application to access an agent using the 

45 Java remote method invocation (RMI) system. As de- 
scribed above, a Java management application access- 
es this server through a managed object adaptor client 
implemented as the Java class sunw.jaw.agent. adaptor. 
rmi.AdaptorClient. 

50 [0118] Core management services can be added to 
an agent while it is running, once the agent has been 
initialised as described above. It is possible to add a core 
service to an agent in either of the following ways: 

55 - directly calling a set method for the service within 
the Framework class; 

adding the service to the m-bean repository in the 
same way as for an m-bean. 
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[0119] Adding a core management service directly 
gives faster performance tinan adding a core manage- 
ment service to tine m-bean repository. TInis is because 
the framework does not need to query the m-bean re- 
pository in order to obtain the service. However, certain 
restrictions can apply to a core management service 
that has been added directly: 

the service is not visible to remote applications; and 
it is not possible to store information on the service 
in persistent storage. 

[0120] Accordingly, where it is desirable for a core 
management service to be visible to remote applica- 
tions, it is necessary to add the service to the m-bean 
repository. If it is desired to store information on a core 
management service in persistent storage, it is also nec- 
essary to add the service to the m-bean repository. The 
m-bean repository to which the service is added, must 
support persistent storage. 

[0121] A Class Service Name contains names by 
which the framework 24 identifies the services that are 
implemented for an agent. The framework 24 retrieves 
the service it requires as follows: 

1 . The framework 24 checks if a service has been 
defined using a direct set method. If a service has 
been defined in this way, the framework 24 uses this 
service. 

2. If the service has not been defined using a direct 
set method, the framework queries the m-bean re- 
pository to obtain all the m-beans that are instances 
of the class that implements the service. For exam- 
ple, for the metadata service, the framework 24 
queries the m-bean repository to obtain all the in- 
stances of the class named ServiceName.META. 

if the repository contains several instances of 
the class, the framework 24 uses the first in- 
stance returned by the m-bean repository, 
if the m-bean repository contains no instances 
of the class, the framework throws a Service- 
NotFound Exception. 

[0122] Various operations can be performed in a net- 
work management service agent. For example, an ob- 
ject in an agent can use core management services for: 

instantiating m-bean; 

registering m-beans with the m-bean repository; 
retrieving m-beans from the m-bean repository; 
getting and setting the values of properties within 
m-beans; and 

defining relationships between m-beans. 

[0123] An object name uniquely identifies an m-bean. 
Management applications use object names to identify 
the m-beans on which to perform management opera- 



tions. Any naming scheme could be used. For example, 
in the preferred embodiment of the invention, a naming 
scheme defined by Microsoft Corporation for the Hyper 
Media Management Scheme (HMMS) could be used. 
5 [0124] In order to instantiate an m-bean, one of the 
following methods of the Framework class can be 
called: 

newObject to user default storage mechanism for 
fo storing the m-bean; 

newDBObject to specify the m-bean is persistent. 

[0125] With either of these methods, it is necessary 
to provide: 

15 

the Java class of the m-bean to be instantiated; and 
the object name to be used for registering the m- 
bean. 

20 [0126] By default, the framework 24 uses the default 
class loader to locate the Java class of the m-bean to 
be created. It then creates an instance of the class. 
Once the m-bean has been instantiated, it is initialised 
and registered so that it is accessible to the framework 
25 24. It is possible to initialise and register an m-bean by 
using: 

a method defined in the m-bean itself; or 
the framework 24. 

30 

[0127] For initialising a register of an m-bean using a 
method defined in the m-bean itself, the Java class def- 
inition of the m-bean should contain: 

55 - an initialisation method; 

the code required to enable the m-bean to register 
itself with the m-bean repository. 

[0128] Once the m-bean has been instantiated, the 
40 framework 24 uses the metadata service 27 to find the 
initialisation method in the newly created m-bean. If 
such a method is present in the m-bean, the framework 
24 calls it giving: 

^5-3 reference to itself as a first parameter; 

the object name for use in registering the m-bean 
as a second parameter. 

[0129] The m-bean is therefore able to register itself 
50 with the m-bean repository using the code provided. 
[0130] If an m-bean is not provided with the initialisa- 
tion method, the framework initialises and registers the 
m-bean using functions provided for this purpose. 
[0131] Registering a JavaBeans component with the 
55 m-bean repository 25 enables the component to be 
managed by the agent 20. Registering the JavaBeans 
component does not require modification of code within 
the JavaBeans component itself. Instead, all that is re- 
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quired is the addition of code for registering it in the m- 
bean repository. Therefore, it is possible to register any 
existing JavaBeans component in the m-bean reposi- 
tory. Once registered, the agent 20 manages the Java- 
Beans component in the same way as any m-bean. 
When an m-bean is registered, it is assigned an object 
name. An object name can be explicitly specified. If an 
object name is not explicitly specified, the framework 24 
assigns a default name to the m-bean. 
[0132] The network management system provides 
services for retrieving m-beans from the m-bean repos- 
itory. These services enable the retrieval of m-beans us- 
ing: 

pattern matching on the object name; or 

queries (filters) on the Java properties they contain. 

[01 33] By using pattern matching on the object names 
of m-beans, it is possible to retrieve: 

a specific m-bean using its full object name; 

a set of m-beans sharing the same logical class as 

expressed in the object name; 

a set of m-beans sharing the same domain name; or 

all the m-beans contained in an agent. 

[01 34] Using queries enables the retrieval of m-beans 
according to Java properties and their values within m- 
beans. The m-bean repository evaluates properties if it 
is able to do so. Otherwise the framework evaluates 
queries itself. To determine whether a repository is able 
to assess queries, the framework causes a query meth- 
od for this purpose. 

[0135] The network management system provides 
services for getting and setting properties of m-beans. 
If the agent provides a metadata service, in a call to the 
get or set method of the m-bean, all that needs to be 
supplied are: 

the name of the property to be retrieved or set; 
the object name of the m-bean that contains the 
property. 

[01 36] If the agent does not provide a metadata serv- 
ice, it is still possible to call directly to the get or set meth- 
od of an m-bean. In this case it is also necessary to sup- 
ply to the caller the name and signature of the method 
to call. 

[0137] A relationship service enables relationships 
between m-beans to be defined when they are required. 
The relationships do not need to be defined in advance. 
Information on the relationships between m-beans is not 
stored with the m-beans themselves, but is stored with 
the relationship. A relationship needs to be registered 
with the m-bean repository. A relationship is defined by: 

a set of roles, for example in an ownership relation- 
ship a person owns a book and a book is owned by 



a person; 

a degree which corresponds to the number of re- 
quired roles in a relationship. 

5 [0138] The m-beans involved in a relationship are re- 
ferred to in a relationship by their object names. A spe- 
cific class loader can be added to the agent at start-up 
or while the agent is running. It is possible to have sev- 
eral class loaders within the same agent, provided that 

fo they are all registered with the m-bean repository. When 
the creation of a new object is requested, it is possible 
to specify the class loader to be used for loading the 
object. In this case the class loader is identified by its 
object name. The system provides several implementa- 

^5 tions of a network class loader, each implementation us- 
ing a different protocol and requiring a different class 
server. 

[0139] The system provides event handling services 
for filtering, logging and forwarding events through dif- 
20 ferent communications protocols. To emit an event, a 
send event method is called. When this method is 
called, the framework 24 retrieves all the m-beans cor- 
responding to an event handling service and calls an 
event handling method of each event handler retrieved. 
25 This method is responsible for handling the events. 
[0140] Figure 9 is a schematic representation of the 
compiling of a c-bean 54 from an m-bean 28. The com- 
piler 60 implements one translation scheme for gener- 
ating c-beans. It is, however, possible to implement dif- 
30 ferent translation schemes depending on the require- 
ments. 

[0141] Figure 1 3 illustrates an example of the output 
of the compiler 60 for compiling a single m-bean called 
A. Figure 14 shows the output of the compiler 60 if a 
55 compiled m-bean includes aListeneMor a specific event 
An Event. 

[0142] Thus, if the m-bean contains listeners, the 
compiler 60 generates: 

40 - a Java interface for the listener to be included in the 
MO interface; 

a listener stub which is an implementation of the m- 
bean listener for catching m-bean events and for- 
warding them to the framework 24; and 
45 - a Java management application's view of the event 
associated to the listener referred to as EventMO. 

[0143] The compiler 60 parses an m-bean using the 
applicable design parameters. After parsing, the com- 
50 piier 60 uses a number of rules for generating the c- 
bean. 

[0144] Each property of the m-bean will be present in 
the c-bean with the same accessor methods. So, if a 
property is read-only in the m-bean, the property will be 
55 read-only in the c-bean. 

[01 45] Figure 1 5A is an illustration of a simple c-bean 
which is generated when compiling an m-bean defined 
by a code example shown in Figure 1 5B. In addition, the 
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compiler 60 generates a file containing an implementa- 
tion of the Simple MO interface. 
[01 46] I n addition to the property accessors, the com- 
piler 60 generates code only for public methods for 
which it makes sense to provide remote access. Other 
public methods do not appear in the c-bean generated 
by the compiler 60. 

[01 47] Figure 1 6A shows a subset for an action meth- 
od in a c-bean of the MO interface which the compiler 
60 will generate when compiling the action method in 
an m-bean defined as in Figure 16B. 
[0148] If an m-bean contains a listener called A, the 
compiler 60 includes a listener called AlfMO in the c- 
bean. 

[0149] When using the c-bean, an application will 
have to implement the Aifmo interface to add or remove 
the listener in the c-bean. Generally, a listener is an in- 
terface containing a certain number of methods. Each 
method has one input parameter. The input parameter 
extends an event object concerned. 
[01 50] I n an example, each method defined in listener 
A refers to an event object which, for the purpose of this 
example is called AnEvent. Accordingly, in the Aifmo in- 
terface, the event object is called AnEventMO. Thus, for 
a listener A, the compiler 60 generates files: 

Aifmo. java; 
AnEventMO. java. 

[0151] In addition, the compiler 60 generates an im- 
plementation of listener A named AStub.java. 
[01 52] Codes generated by the compiler 60 complies 
with the design parameters designed by the JavaBeans 
component model. Accordingly, the objects generated 
by the compiler 60 can be integrated in development en- 
vironments that comply with this model. In addition, the 
compiler 60 adds some public methods which do not fol- 
low the design patterns defined by the JavaBeans com- 
ponent model. The added methods are designed to limit 
the network traffic between an m-bean and a c-bean. 
For example, by calling one function on a c-bean, it is 
possible to read all the properties of the corresponding 
m-bean. 

[01 53] The compiler 60 generates Java source code. 
It is possible to edit the generated code and modify it to 
define a specific view of an m-bean. Instead of modifying 
both the interface and the stub, it is better to keep the 
interface and modify only the stub. The code generated 
by the compiler 60 enables an application to be built us- 
ing the interface. At one time the behaviour will change 
depending on which stubs are loaded by the adaptor- 
MO. For instance, the compiler can generate read-only 
or read-write stubs for the same interface. Accordingly, 
an m-bean browser can be developed based on the in- 
terface. As mentioned above, the browser will thereby 
have a different behaviour depending on whether the 
read-only or read-write stubs are loaded. 
[0154] The adaptorMO interface is a Java interface 



defined for managing the agent 20. The network man- 
agement system provides several implementations of 
the adaptorMO interface based on different communi- 
cations protocols, as described above. However, the 
5 adaptorMO interface is protocol independent. Accord- 
ingly, any piece of code written using the interface can 
run on any of the implementations provided by the net- 
work management system. 

[0155] Within the adaptorMO interface there are two 

10 different levels. A low level where remote objects (m- 
bean) are manipulated using their names, and a high 
level where remote objects (m-bean) are manipulated 
using a local view (c-bean) of the remote objects. The 
high level is built on top of the low level interface. 

15 [0156] Using the low level interface is practical for 
building generic applications (such as an HTML object 
viewer or MIB browser). Using the high level interface 
is much easier than using the lower level interface. How- 
ever, it means that the application knows the semantic 

20 of the c-beans it manipulates. In addition, it requires the 
application (or the adaptorMO interface) to have access 
to MOs and MOStubs. A first step in initialising an adap- 
tor consists of initialising an implementation of the adap- 
torMO interface. 

25 [0157] In order to initialise an adaptor, the client ap- 
plications invokes a "connect" method defined in the 
adaptorMO interface. Parameters are provided which 
relate to the host name of the agent, the port number to 
use and a logical name which is generally dependent 

30 on the underlying communication mechanism. The dif- 
ferent piece of information could be obtained from a 
name server or directory service at the same time the 
implementation name of the adaptor to use is given. De- 
pending on the underlying communication mechanism 

35 used by the adaptorMO interface, the call to "connect" 
might not involve any message exchange between the 
client and agent. 

[0158] An adaptor makes use of: 

40 - a name server for getting the Java class name for 
use for representing a specific m-bean (known 
through its object name); 
a class loader for loading c-beans. 

45 [0159] If all the Java classes for the c-beans are 
present on the machine where the client application is 
running, there is no need to use a specific class loader. 
Otherwise, it is possible to use a network class loader 
for getting the classes over the network. 
50 [0160] For using a network class loader, a client ap- 
plication needs to instantiate the network class loader. 
When instantiating the object, the application provides 
an object name. The object name can contain any do- 
main and any class name. However, the object name 
55 should contain the following key properties: 

host (the host name where the class server is run- 
ning); 
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port (the port number to use); 

service (the name of the RMI service to invoke). 

[0161] Once an adaptor is initialised, the application 
is ready to perform management operations on the re- s 
mote agent. An application can retrieve a subset or all 
of the m-beans managed by an agent. When retrieving 
objects, an application can specify queries. The results 
of the retrieval can be obtained under two different 
schemes: fo 

a list of object names (represented by a Vector); 
a list of c-beans (for each object name retrieved the 
adaptor will instantiate a c-bean). 

15 

[0162] In order to read a property of a remote m-bean, 
the property name is needed when using the low level 
adaptorMO interface level. When using the high level 
interface, the c-bean is retrieved and then a getter as- 
sociated to the property is invoked. 20 
[01 63] Setting a property of a remote m-bean, a prop- 
erty name and the property object type is required when 
using the low level adaptorMO interface level. When set- 
ting a value, it is possible to specify the name of an op- 
erator class. On the agent side, the specified operator 25 
is instantiated and invoked for setting the property value. 
When using the low level adaptorMO interface level, it 
is possible to set several properties through one method 
call using a list of modifications. 

[0164] When using the high level adaptorMO inter- 30 
face level, a c-bean is obtained and the developer then 
invokes the set associated to the property 
[01 65] Through the adaptorMO interface, it is possible 
to request instantiated of m-beans within a remote 
agent. When requesting the instantiation, it is possible 55 
specify a new class loader through which the agent is 
supposed to load the new class to instantiate. The class 
loader can be specified using its object name. If no class 
loader is specified, the agent uses the default class load- 
er. When instantiating a remote m-bean, it is possible to 40 
directly obtain a c-bean for representing the newly cre- 
ated m-bean. If no name is provided and if a name serv- 
er is specified, the adaptor queries the name server in 
order to obtain the name of the Java class to instantiate 
on the agent's side. Otherwise, it is the responsibility of 45 
the agent to determine the class name of the class to 
instantiate. When instantiating an m-bean in the agent, 
it is possible to explicitly request the object to be per- 
sistent. 

[0166] Through the adaptorMO interface, it is possible 50 
to transfer Java objects from the client to the agent. In 
order to do this, the adaptorMO interface serialises the 
object, sends the object over and deserialises the object 
in the agent. 

[0167] Through the adaptorMO interface, it is also 55 
possible to remove an m-bean object from the remote 
agent. The m-bean is not removed from the virtual ma- 
chine, but only from the object repository of the agent. 



[01 68] Figure 1 7 is a flow diagram giving an overview 
of the steps in creating and operating a management 
system as described above including steps of defining 
a network management model including at least one 
management bean using a bean-based environment 
and compiling said model to implement said computer 
network management system in said bean-based envi- 
ronment. 

[0169] In step 110, a model is created using a bean- 
based environment. A preferred bean-based environ- 
ment is Java environment with the beans being Java- 
Beans. 

[0170] As mentioned above, beans provide a set of 
properties, a set of methods for performing actions, and 
support for events and for introspection. Conventionally, 
the properties allow beans to be manipulated program- 
matically and support customization of the bean, the 
methods implement the properties and the support for 
events enables beans to fire events and define the 
events which can be fired. The support for introspection 
enables the properties, events and methods of the bean 
to be inspected from externally. 

[0171] Accordingly, step 110 includes generating at 
least one said management bean providing at least one 
property for modelling a property of a managed re- 
source, and/or a method for modelling an action for said 
managed resource and/or support for at least one event 
for modelling an event of said resource and/or support 
for introspection permitting external analysis of the com- 
position of said bean. This step also includes defining 
the relationship and interactions between management 
beans as representative of the relationships and inter- 
actions between the managed resources. This step can 
also include defining at least one listener event in re- 
spect of at least one management bean. 
[0172] It is recognised for the first time in respect of 
the present network management system that beans 
can be used beyond their conventional role to provide 
a management vehicle (management bean) for directly 
modelling resources to be managed. For example, a 
property in a management bean can be used for mod- 
elling a property (e.g. a resource attribute such as the 
size of a memory, the number of messages received in 
a buffer, etc) of a managed resource. A method of a 
management bean can be used for modelling an action 
(e.g. a system rest) of a managed resource. A bean can 
also be used to provide support for an event (for exam- 
ple a disk full event) for a managed resource. For ex- 
ample, a management bean can provide support for a 
listener event, whereby one management bean can be 
responsive to an event on another management bean. 
By means of the support for introspection a manage- 
ment bean can permit external analysis of the compo- 
sition of the bean and the exchange of information be- 
tween beans. Management beans can include defini- 
tions of relationships and interactions between manage- 
ment beans as representative of the relationships and 
interaction between the managed resources. 



14 



27 



EP 0 909 058 A2 



28 



[0173] As beans are reusable software components 
which can be manipulated visually in a builder tool (e.g. 
an editor or graphical user interface builder (GUI build- 
er)), in step 110 a user can use a conventional builder 
tool, such as the JavaBeans Development Kit, for gen- s 
erating the management system model including beans 
defining system resources, their functions and the rela- 
tionships between and interactions of the system re- 
sources. The bean model is defined within a virtual ma- 
chine forming the bean-based environment, for example fo 
a model using JavaBeans within a Java virtual machine. 
This greatly facilitates the generation of the manage- 
ment system model. Verification and debugging of the 
model can be readily performed using introspection and 
other techniques. ^5 
[0174] In step 112, once the model has been gener- 
ated, the model can be compiled directly using a con- 
ventional compiler for the bean-based environment, for 
example the compiler 60 shown in Figure 9. By defining 
a model in a bean-based environment, it is possible di- 20 
rectly to compile the bean-based model to form a bean- 
based implementation using a standard compiler for the 
bean-based environment, for example by compiling the 
JavaBeans using a Java compiler. Accordingly, the re- 
sulting bean management system is also defined within 25 
the same Java environment. This greatly simplifies this 
stage of the generation of management system as the 
compiler forces a reliable and homogeneous implemen- 
tation of the model. 

[0175] At runtime, therefore, in step 114, the manage- 30 
ment system described earlier in this document pro- 
vides a robust and readily modifiable structure, without 
the difficulties and disadvantages of prior network man- 
agement system. 

[0176] Step 114 includes the steps described in re- 55 
spect of Figure 12 of registering one or more manage- 
ment bean(s) with the extensible agent framework; reg- 
istering one or more network adaptor(s) (e.g. network 
adaptor bean(s)) for a network communications protocol 
with the extensible agent framework; and enabling ex- 40 
ternal access via the network to the management bean 
(s) via the network adaptor(s). 

[01 77] As described with respect to Figure 1 2, the ex- 
tensible agent framework can include an associated re- 
pository bean and the steps of registering one or more 45 
management bean(s) and/or network adaptor(s) can 
comprise registering one or more management bean(s) 
and/or network adaptor(s) with the repository bean. 
[0178] Thus, there has been described a network 
agent for a telecommunications network, which network 50 
agent includes an extensible framework, one or more 
managed objects registerable with the framework and 
one or more network adaptors registerable with the 
framework for a network communications protocol for 
enabling access to the managed objects. The network 55 
agent provides a flexible mechanism for a dynamic net- 
work management environment. Registration with the 
framework can be by means of a repository service ob- 



ject. The managed object is preferably a bean which 
comprises a set of properties, a set of methods and sup- 
port for events and for introspection. There has also 
been described a method of providing agent service and 
a network management system using such an agent. 
[0179] The network agent can be implemented in the 
form of software on at least one storage medium. The 
storage medium could be a portable storage medium 
such as a magnetic, opto-magnetic or optical disk and/ 
or a solid state memory and/or the memory of a server 
computer. The network agent can be loaded into mem- 
ory of a managed system by connecting the portable 
storage medium or by down-loading from the server and 
executed by the processor at the managed system. Al- 
ternatively, the network agent could be implemented, at 
least in part, by special purpose firmware or hardware. 
[0180] It will be appreciated that although particular 
embodiments of the invention have been described, 
many modifications/additions and/or substitutions may 
be made within the scope of the present invention. 



Claims 

1 . A network agent for a telecommunications network, 
said network agent comprising: 

an extensible framework; 

one or more managed objects registerable with 

said framework; and 

one or more network adaptors registerable with 
said framework for a network communications 
protocol for enabling access to said managed 
objects. 

2. The network agent of Claim 1 , comprising a repos- 
itory service object registrable with said framework, 
said managed object(s) and/or said network adap- 
tor(s) and/or one or more further service objects be- 
ing registrable with said repository service object, 
whereby said managed object and said network 
adaptors are registerable indirectly with said frame- 
work via said repository service object. 

3. The network agent of Claim 2, wherein said network 
adaptor(s) comprise network adaptor object(s). 

4. The network agent of Claim 3, wherein a said man- 
aged object is a bean which comprises a set of prop- 
erties, a set of methods for performing actions, and 
support for events and for introspection. 

5. The network agent of any preceding claim, wherein 
said framework comprises getter and setter proper- 
ties and implements getter and setter methods for 
getting and/or setting objects and/or object meth- 
ods. 
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6. The network agent of Claim 7, wherein a said net- 
work adaptor is responsive to a received external 
request to cause said framework to get a managed 
object method for said request and to return a sub- 
sequent response. 

7. The network agent of Claim 6, comprising an repos- 
itory service object registrable with said framework, 
said managed object(s) and/or said network adap- 
tor(s) being registrable with said repository service 
object, whereby said managed object and said net- 
work adaptors are registerable indirectly with said 
framework via said repository service object, said 
framework referencing said repository service for 
calling said managed object method. 

8. The network agent of Claim 5, wherein said frame- 
work is arranged to effect add object and remove 
object functions. 

9. The network agent of any preceding claim, wherein 
said framework is a bean which comprises a set of 
properties, a set of methods for performing actions, 
and support for events and for introspection. 

10. An object-based network agent on a carrier medi- 
um, said network agent comprising means operable 
to define: 

an extensible framework service object; 
one or more managed objects registerable with 
said framework service; and 
one or more network adaptor objects register- 
able with said framework service for a network 
communications protocol for enabling access 
to said managed objects. 

11. A computing system connectable to a telecommu- 
nications network, said computing system including 
an network agent according to any one of Claims 1 
to 10. 

12. A network management system comprising a net- 
work agent according to any one of Claims 1 to 10. 

1 3. A method of providing agent services via a telecom- 
munication network, said method comprising steps 
of: 

dynamically registering one or more managed 
objects with an extensible agent framework; 
registering one or more network adaptors for a 
network communications protocol with said 
framework; and 

enabling access to said managed object(s) via 
said network adaptor(s). 

14. The method of Claim 13, wherein said framework 



comprises an associated repository object and said 
registering steps comprise registering said man- 
aged objects and/or said network adaptors with said 
repository object. 

5 

15. The method of Claim 14, wherein a said network 
adaptor is responsive to a received external request 
to cause said framework to call a managed object 
method for said request and to return a subsequent 

fo response. 

16. The method of Claim 15, wherein said network 
adaptor(s) comprise network adaptor object(s). 

^5 17. The method of any one of Claims 1 3 to 16, wherein 
a said object comprises a set of properties, a set of 
methods for performing actions, and support for 
events and for introspection. 

20 18. The method of Claim 17, wherein said object is a 
bean. 
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package sunw.jaw.example. mo. Simple; 

* Generated by mogen Compiler version; 

@ (#) Main.java 1.11 97/05/16 SMI 

*/ 

import java.jaw. common.*; 
import javajaw.client.mo.*; 

public interface SimpleMO extends ManagedObject { 
public String getStateQ 

throws InstanceNotFoundException, CommunicationException, 
lllegalAccessException, ServiveNotFoundException, 
PropertyNotFoundException; 

public Integer getNbChanges () 

throws InstanceNotFoundException, CommunicationException, 
lllegalAccessException, ServiceNotFoundException, 
PropertyNotFoundException; 

public void setState (String value) 

throws InstanceNotFoundException, CommunicationException, 
lllegalAccessException, ServiceNotFoundException, 
PropertyNotFoundException, InvalidPropertyValueException, 
InstantiationException, CiassNotFoundException; 

} 

FIG. 15A 
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package sunw.jaw. example. mo. Simple; 

* Very simple of definition of a Beans MO 

* No special import required. 

*/ 

public class Simple implements java.io.Serializable { 
private String state; 
private Integer nbChanges; 

public Simple () { 

state = "construct"; 
nbChanges = new Integer (0); 

} 

public String getState () { 
return (state); 

} 

public void setState (String s) { 
state = s; 

nbChanges = new integer (nbChanges. intValue () + 1); 

} 

public Integer getNbChanges () { 
return (nbChanges) ; 

} 



FIG. 15B 
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public interface simpleMBeanMO extends ManagedObject { 
« • « • 

public Boolean performReverse (integer pO) 

throws InstanceNotFoundException, CommunicationException, 
lllegalaccessException, Sen/iceNotFoundException, 
NoSuchMethodException; 

public void performReverse 
throws InstanceNotFoundException, CommunicationException, 
IliegalAccessException, ServiceNotFound Exception, 
NoSuchMethodexception; 



} 

FIG.16A 



public class simpleMBean implements java.io.Seriallzable { 

public void performReverse () { 

StringBuffer buf = new StrlngBuffer (name); 

name = buf.reverse Q.toString (); 

} 

public Boolean performReverse (Integer nFirst) { 
StringBuffer buf = new StringBuffer (); 
int n = nFirst. intValue (); 

if (name. length () < n + 1) { 
return (new Boolean (false)); 

} 

buf.append (name. substring (0, n)); 

name = new String (buf.reverse ().toString () + 
name. substring (n)); 

return (new Boolean (true)); 

} 

• • • 

_2 

FIG. 16B 
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